home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Atari Compendium
/
The Atari Compendium (Toad Computers) (1994).iso
/
files
/
umich
/
utils
/
date.arc
/
README
< prev
Wrap
Internet Message Format
|
1989-05-25
|
4KB
From: dal@syntel.UUCP (Dale Schumacher)
[close@cacilj.UUCP (Diane Barlow Close) writes...]
> In article <3229@cs.dal.ca> silvert@cs.dal.ca (Bill Silvert) writes:
>>- I asked about a bug I have run into, and they hadn't run into it --
>> have any of you? My date function doesn't work, it always generates a
>> date on Jan. 1 some year in the 21st century (which year I forget).
>> The guy I spoke for said it works for him. Perhaps it involves my
>> clock-setting software -- I use the clock that comes with the Supra
>> 60-Meg hard drive, which seems to work fine for everything else.
>> Anyone have any idea what the problem might be? It would be a very
>> useful function if I could get it to work!
>
> There are actually 3 clocks in the ST. They are the keyboard clock, the TOS
> clock, and the BIOS clock. Some hard drives set only one clock. My BMS card
> sets only the TOS clock. If I remember correctly, I think WP uses the BIOS
> clock (a leftover from PC days, perhaps?). Since the BMS clock only sets the
> TOS clock, my time and date in WP are screwed up (Jan 20 20??, way in the
> future).
I don't think there are really 3 clocks in the ST, only 2, but you're on
the right track. The Supra SUPCLKRD program reads the clock in the disk
drive and sets the GEMDOS time accordingly. The GEMDOS time (or system
time) is reset on even a warm-boot and defaults to some time in 1985.
This is the time used to time-stamp files when they are created and is
the most often used time reference. The BIOS time (or keyboard time) is
maintained by the processor in the keyboard and is independent of the
system clock. It also retains it's time setting through a warm-boot, but
not through a cold-boot. On cold-boot (power off), the keyboard clock
defaults to the 20xx year value described above.
> To fix this irritating problem, my husband wrote a small program in Mark
> William's C that sets the BIOS clock. Since it's a small program, I'll
> include it here:
>
> /* set all clocks according to TOS time */
>
> #include <time.h>
> #include <osbind.h>
>
> main() {
> tetd_t td;
>
> td = ((long)Tgetdate()<<16) | (unsigned)Tgettime();
> Settime(td);
> Ksettime(tetd_to_tm(td));
> }
There are a number of MWC specific features here, like Ksettime() and
tetd_to_tm(), so I'm not certain what this is really doing, but I assume
that it "does the right thing" when compiled with MWC. From the operating
system level there are a set of GEMDOS functions for reading/setting the
system time, they are:
#define Tgetdate() (int)gemdos(0x2A)
#define Tsetdate(date) gemdos(0x2B,date)
#define Tgettime() (int)gemdos(0x2C)
#define Tsettime(time) gemdos(0x2D,time)
...and there are a couple of XBIOS functions for reading/setting the
keyboard time, they are:
#define Settime(time) xbios(22,time)
#define Gettime() xbios(23)
The parameters for these calls differ considerably, so you should look
them up before trying to use these calls. I expect that the problems
of the original poster were due to using the XBIOS calls and thus refering
to the keyboard clock, which wasn't being set properly.
...AND NOW FOR SOMETHING COMPLETELY DIFFERENT... A BUG REPORT!
There is a nasty bug that crops up when you are working with both clocks
at the same time. If you read the system date and time, then read the
keyboard time, and immediately set the system date and time, the KEYBOARD
clock will stop counting and seems to set itself to an unusual value.
If you read the keyboard clock first, then the system, and then set the
system time, everything works just fine.
Here is a program which handles all of these problems correctly, sets
both clock, works nicely from the /AUTO/ folder and is fairly intelligent
about determining good defaults for the time.